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Definition of an IS-IS Link Attribute Sub-TLV 
Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


This document defines a sub-TLV called "Link-attributes" carried 
within the TLV 22 and used to flood some link characteristics. 
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Introduction 


[IS-IS] specifies the IS-IS protocol (ISO 10589) with extensions to 
support IPv4 in [RFC1195]. A router advertises one or several Link 
State Protocol data units that are composed of variable length tuples 
called TLVs (Type-Length-Value). 


[RFC3784] defines a set of new TLVs whose aims are to add more 
information about links characteristics, increase the range of IS-IS 
metrics, and optimize the encoding of IS-IS prefixes. 


This document defines a new sub-TLV named "Link-attributes" carried 
within the extended IS reachability TLV (type 22) specified in 
[RFC3784]. 


1 Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


Link-Attributes Sub-TLV Format 


The link-attribute sub-TLV is carried within the TLV 22 and has a 
format identical to the sub-TLV format used by the Traffic 


Engineering Extensions for IS-IS ([RFC3784]): 1 octet of sub-type, 1 
octet of length of the value field of the sub-TLV followed by the 
value field -- in this case, a 16 bit flags field. 


The Link-attribute sub-type is 19 and the link-attribute has a length 
of 2 octets. 


This sub-TLV is OPTIONAL and MUST appear at most once for a single IS 
neighbor. If a received Link State Packet (LSP) contains more than 
one Link-Attribute Sub-TLV, an implementation SHOULD decide to 
consider only the first encountered instance. 


The following bits are defined: 


Local Protection Available (0x01). When set, this indicates that the 
link is protected by means of some local protection mechanism (e.g., 
[RFC4090]). 


Link excluded from local protection path (0x02). When set, this link 
SHOULD not be included in any computation of a repair path by any 
other router in the routing area. The triggers for setting up this 
bit are out of the scope of this document. 
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3. Interoperability with Routers Not Supporting This Capability 


A router not supporting the link-attribute sub-TLV will just silently 
ignore this sub-TLV. 


4. IANA Considerations 


IANA has assigned codepoint 19 for the link-attribute sub-TLV defined 
in this document and carried within TLV 22. 


IANA has created a registry for bit values inside the link-attributes 
sub-TLV. The initial contents of this registry are as follows 


Value Name Reference 
0x1 Local Protection Available [RFC5029] 
0x2 Link Excluded from Local Protection [RFC5029] 


Further values are to be allocated by the Standards Action process 
defined in [RFC2434], with Early Allocation (defined in [RFC4020]) 
permitted. 


5. Security Considerations 


Any new security issues raised by the procedures in this document 
depend upon the opportunity for LSPs to be snooped and modified, the 
ease/difficulty of which has not been altered. As the LSPs may now 
contain additional information regarding router capabilities, this 
new information would also become available to an attacker. 
Specifications based on this mechanism need to describe the security 
considerations around the disclosure and modification of their 
information. Note that an integrity mechanism, such as one defined 
in [RFC3567], should be applied if there is high risk resulting from 
the modification of capability information. 
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